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DETAILED ACTION 

1. This action is responsive to the Applicant's response filed 2/22/2005. 

As indicated in Applicant's response, claims 4-5, 8-10, 16-21, 23-25 are canceled, claims 
3, 6, 22, 27 have been amended; and claims 39-42 are added. Claims 1-3, 6-7, 1 1-15, 22, 26-42 
are pending in the office action. 

Claim Rejections - 35 USC §101 

2. 35 U.S.C. 101 reads as follows: 

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or 
any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and 
requirements of this title. 

3. Claims 3, 6 and 39-41 are rejected under 35 U.S.C. 101 because the claimed invention is 
directed to non- statutory subject matter. 

The Federal Circuit has recently applied the practical application test in determining whether the claimed 
subject matter is statutory under 35 U.S.C. § 101. The practical application test requires that a " useful, concrete, 
and tangible result" be accomplished. An "abstract idea" when practically applied is eligible for a patent. As a 
consequence, an invention, which is eligible for patenting under 35 U.S.C § 101, is in the "useful arts" when it is a 
machine, manufacture, process or composition of matter, which produces a concrete, tangible, and useful result. The 
test for practical application is thus to determine whether the claimed invention produces a "useful, concrete and 
tangible result". 

Claim 3 recites a method in developing software comprising comparing 2 documents, 
determining whether there are more differences than a pre-determined number and if so 
indicating the differences. These are steps to determine whether some differences exist in one 
document with respect to another but absent is any action requiring a tangible utility and 
performed in order to yield the concrete result so that the result is tangible as required by the 
practical application test as mentioned above. The steps recited can be performed without a 
hardware support in a manner of for example, a paper/pencil process. The claim therefore is no 
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more than an impractical and/or abstract idea; and is rejected for leading to a non-statutory 
subject matter. 

Claim 39 recites a method having the same steps of comparing, determining, and 
indicating as recited in claim 3, does not amount to any action depicting a tangible utility being 
used nor does the claim amount to a result being tangible as set forth above, i.e. a sequence of 
step actions that can be done via a mental process without hardware support. Thus the claim 
merely amounts to an abstract idea; and is rejected for leading to a non-statutory subject matter. 

Claims 6 and 40-41 are also rejected for failing to remedy to the deficiencies of the base 

claims. 

Claim Rejections - 35 USC §112 

4. The following is a quotation of the first paragraph of 35 U.S.C. 1 12: 

The specification shall contain a written description of the invention, and of the manner and process of making 
and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it 
pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode 
contemplated by the inventor of carrying out his invention. 

5. Claims 3, 6 and 39-41 are rejected under 35 U.S.C. 101 because the claimed invention is 
not supported by either a specific asserted utility or a well-established utility. 

The claims 3 and 39 only provide step actions that reasonably can be done mentally thus 
without any hardware utility and support; and such omission of tangible support is rejected here 
above as not fulfilling the practical application test requirement. 

Claims 3, 6 and 39-41 are also rejected under 35 U.S.C. 1 12, first paragraph. 
Specifically, since the claimed invention is not supported by either a specific and tangible 
asserted utility or a well established utility for the reasons set forth above, one skilled in the art 
clearly would not know how to use the claimed invention. 
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Claim Rejections - 35 USC §102 

6. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public use or on 
sale in this country, more than one year prior to the date of application for patent in the United States. 

7. Claims 1 1-12, and 15 are rejected under 35 U.S.C. 102(b) as being anticipated by 
Leblang et al., USPN: 5,649,200 ( hereinafter Leblang). 

As per claim 11, Leblang discloses a method useful in developing software having 
multiple versioned documents, comprising: 

comparing 2 child documents of a common parent document with each other and 
indicating any differences as actual conflicts between the two (e.g. Fig. 3); 

comparing both child documents with a common parent for indicating possible conflicts 
between child documents for portions therein that are same to each other (e.g. Fig. 13, 16 - Note: 
X being at root of tree reads on common parent to child documents in the process for detecting 
possible conflicts or delta); 

producing a merged output document indicating both actual and possible conflicts (e.g 
result of ... merge ; {deltaA + (- deltaA)+ deltaB + deltaC)- Fig. 13,16- Note: intermediate 
deltas arithmetic in order to yield a actual delta resulting therefrom reads on having possible 
conflicts which after being resolved yield that resultant actual conflict). 

As per claim 12, Leblang discloses delta as being recorded from previous version of 
child documents and being reused for unmerging ( e.g. substractive merge - Fig. 16 - Note: 
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keeping track of previous conflicts in order to perform selective unmerging reads on alternative 
histories of child documents being stored). 

As per claim 15, this is a computer-readable medium version of claim 1 1. As for a 
medium to support the software product, Leblang( Fig. 1, 2, 6) discloses use of workstations to 
develop the software building, hence implicitly discloses the use of computer-readable medium. 
8. Claims 22, and 26-29 are rejected under 35 U.S.C. 102(b) as being anticipated by Carrier 
III et al., USPN: 5,903,897 (hereinafter Carrier). 

As per claim 22, Carrier discloses a method useful in developing software having 
multiple versioned documents, comprising: 

associating like versions of versioned documents with each other in a change set 
specification (e.g. released forms - col. 6, lines 17-52; Fig. 5-6 - Note: like versions reads on 
file selected for a release) by listing each of the versioned documents in a association file that 
designates the like versions to be incorporated in the change set specification (e.g. source 
modules step 160, release forms step 162, Fig. 3; ; col. 4, lines 54-62 —Note: release from 
different reasons reads on change set and multi association of source modules checked in a 
release form reads on listing of versioned documents in a association file) 

associating additional, non-versioned documents into the same change set (e.g. step 328 - 
Fig. 9; build log 550, test cases 520, build report 552- Fig. 12); by listing non-versioned 
documents into the change set ( e.g. col.7, lines 32-42; Fig. 9; load 366, Fig. 10 - Note: 
appending to the check-in source data some load data, depicting corresponding problem reports, 
label and name and version reads on listing of non-versioned data) 
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retrieving both versioned and non-versioned documents as a single unit (e.g. source files 
and check-in info, defect tracker -Fig. 11; Fig 12); 

storing the association file in a memory separately from the documents listed in the file 
(e.g. Fig. 1; check-in data - col. 3, line 62 to col. 4, line 10; col. 4, line 48 to col. 5, linel8 - 
Note: source files being in database of software control system and later attached to a logical 
grouping called release forms being prompted at the release building tool reads on association 
file residing —in the load builder— separate from source files being persisted and checked in a 
version database) 

As per claim 26, this is a computer medium version of claim 22 with the medium 
limitation being disclosed by Carrier (medium driver 60 - Fig. 1). 

As per claim 27, Carrier discloses an association file (released forms - col. 6, lines 17- 
52; Fig. 5-6) for a set of versioned documents, comprising 

a plurality of entries each functioning to designate a version of the versioned documents 
to be incorporated in a change set (e.g. source modules step 160, release forms step 162, Fig. 3; 
col. 4, lines 54-62 —Note: release from different reasons reads on change set) corresponding to a 
software under development ( Note: change set reads on software development not yet 
accomplished); 

at least one entry functioning to designate a non-versioned document pertaining to at least 
one versioned documents to be incorporated in a change set (e.g. step 328 - Fig. 9; build log 550, 
test cases 520, build report 552- Fig. 12 ); the non-versioned document providing useful 
information, the association file associating versioned documents and the non-versioned 
document in a single file (e.g. Fig. 9; load 366, Fig. 10 - Note: appending to the check-in source 
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data some load data, where in each problem report in conjunction w/ label and name and version 
reads on non-versioned document useful for the single association file, i.e. change set or release 
form) 

As per claim 28 and 29, Carrier discloses incorporating in the change set non-versioned 
design documentation (e.g. col. 8, lines 20-36) and bug report (e.g. reporting tool 24, defect 
tracker 32, build report 52 - Fig. 1; release form ... report number - col. 4, line 54-62). 

9. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed in the 
United States before the invention by the applicant for patent or (2) a patent granted on an application for patent by 
another filed in the United States before the invention by the applicant for patent, except that an international 
application filed under the treaty defined in section 351(a) shall have the effects for purposes of this subsection of an 
application filed in the United States only if the international application designated the United States and was 
published under Article 2 1 (2) of such treaty in the English language. 

Note: 35 U.S.C. § 102(e), as revised by the AIPA and H.R. 221 5, applies to all qualifying references, except when the 
reference is a U.S. patent resulting directly or indirectly from an international application filed before November 29, 
2000. For such patents, the prior art date is determined under 35 U.S.C. § 102(e) as it existed prior to the amendment 
by the AIPA (pre-AIPA 35 U.S.C. § 102(e)). 

10. Claims 31-38 are rejected under 35 U.S.C. 102(e) as being anticipated by Hopwood et al., 
USPN: 6,223,343 (hereinafter Hopwood). 

As per claim 31, Hopwood discloses a method useful in developing software having 
multiple versioned documents, comprising: 

synchronizing a set of files from a common storage area to a private enlistment area (e.g. 
e.g. col. 19, lines 36-63; Fig. 3; col. 17, line 50 to col. 18, line 39; workstation 96- Fig. 7 - 
Note: host developer workstation reads on enlistment area where files in RMS are checked out 
for synchronization and selection by developer); 



Application/Control Number: 09/717,676 Page 8 

Art Unit: 2193 

adding a set of build-specific changes to the files in the enlistment area (e.g. col. 17, line 
50 to col. 18, line 39); 

making local changes to the enlisted files (e.g. col. 19, lines 36-63; Fig. 3; step S50 - Fig. 

8); and 

returning enlistment files to the common area ( e.g. Revision control, RMS , archive, 
historical record col. 18, lines 40-52; Fig. 8-9 Note: the RMS and the check in/out reads on 
returning a unchanged version in the archive directory as opposed to getting a copy and applied 
needed changes thereto and returning such copy to another sub tree of the archive) 

Hopwood further discloses removing the build-specific changes from the enlisted files by 
means of REVER T utility in a RMS system wherein a team member is modifying copies of check 
out files based on historical records (e.g. pg. 28, lines 54-55; master copy ... archive ... retrieve 
and modify - col. 18, lines 40-52; Fig 13-17); such reverting process in conjunction with 
persisting or archiving change information in a historical manner reads on changes being 
removed from a specific build/version level to restore to its previous original state/level of a file 
being enlisted for modification). 

As per claim 32, Hopwood discloses repeating the enlistment process (e.g. inventory 
groups - Fig. 8 - Note: plurality of inventory groups reads on repeating of enlistment process). 

As per claim 33, Hopwood discloses an common area for all separate enlistment areas ( 
e.g. col. 15, line 4-35 - Note: per host workstation, a RMS is a shared area for all enlistments 
viewed by the user of that workstation, hence common to all separate views). 

As per claim 34, see Hopwood, Fig. 7; synchronize inventory, merge elements -Fig 12; 
refer to enlistment area of claim 1 . 
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As per claim 35, Hopwood discloses merging with a set of previous local changes (e.g. 
col. 19, lines 36-63; synchronize inventory, merge elements -Fig 12). 

As per claim 36, Hopwood discloses getting the build-specific changes from a build area 
(e.g. Fig. 13-14; col. 17, line 50 to col. 18, line 39 - Note: locked by issuance reads on getting 
build-specific changes); and merging the build-specific changes into the enlistment files (e.g. see 
claim 35 - Note: merging different files from RMS - see Fig. 6-7, 13 - 14 -- in order to group 
into a set for a build/issuance reads n merging build-specific changes). 

As per claim 37, Hopwood discloses selecting a particular build from which to get the 
specific changes (Note: the involvement of developer and an issuance instance from Fig. 6-7, 13- 
14 implicitly disclose selecting of a particular build). 

As per claim 38, this is a computer-readable medium version of claim 1 . As for a 
medium to support the software product, Hopwood discloses use of workstations to develop the 
software building (e.g. Fig. 7) hence implicitly discloses the use of computer-readable medium. 

Claim Rejections - 35 USC §103 

11. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

12. Claims 1-2 are rejected under 35 U.S.C. 103(a) as being unpatentable over Hopwood et 
al., USPN: 6,223,343; in view of Leblang et al., USPN: 5,649,200. 

As per claim 1, Hopwood discloses a method for developing software having multiple 
versioned documents, comprising: 
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comparing multiple ones of the versioned elements of a project at different subdivision 
level ( e.g. merge elements 7tf-Fig. 12; Fig. 15-20; Fig. 8, 11; col. 14, lines 32-36; col. 18, lines 
23-46; merge -col. 19, lines 36-47 - Note: management of change to level of logical group 
elements to record changes using merge tool is equivalent to comparing versioned) and 
indicating the changes on elements of workgroups at each subdivision level ( e.g. record of ... 
changes - col. 19, line 47 to col. 20, line 10; Fig. 15); 

unmerging from a later version of versioned documents of changes previous to a further 
set of changes (e.g. regression, restore, revert - col. 28, lines 45-55 ); 

associating with the set of changes in versioned documents a plurality of non-versioned 
documents pertaining respectively to versions of versioned documents (e.g. issuance control 
data, maintenance libraries, audit trails, issuance reports, metadata - col. 13, line 63 to col. 14, 
line 14; difference reports - col. 19, lines 36-40 - Note: each element retrieved for work group 
build is equivalent to versioned document); 

updating by copying files from a common storage area to a private enlistment area, 
adding build-specific changes to enlistment copies, making changes to the modified copies (e.g. 
col. 19, lines 36-63; Fig. 3; host developer workstation - col. 17, line 50 to col. 18, line 39; 
workstation 96 - Fig. 7 ) and thereafter removing the changes and returning the files to the 
common area (e.g. master copy - col. 18, lines 40-52 - Note: master copy is equivalent to 
storing/keeping of copies without added changes back into the repository). 

But Hopwood does not explicitly specify comparing of versioned documents to a 
common parent document and indicating conflicts caused by alternative histories from the parent 
document. Hopwood teaches merging and validating of software elements persisted in a 
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hierarchy of a version control RMS (e.g. Fig. 11; col. 18, line 40 to col. 19, line 48; col. 15, lines 
14-26; Fig. 8) which suggests conflict resolving with changes in the hierarchy of version tree and 
comparing modified file against persisted earlier change. Leblang, in a method to 
compare/merge files in a hierarchy of development environments similar to built environment as 
taught by Hopwood, discloses comparing multiple versioned child documents to a parent 
document and recording conflicts or of possible conflicts/deltas being reused for selectively 
removing delta (e.g. Fig. 13, 16 - Note: 1) highest level base level of tree is parent; 2) possible 
conflicts is being taught via the intermediate conflicts being resolved to yield the actual resultant 
conflict - re claim 11). It would have been obvious for one of ordinary skill in the art at the 
time the invention was made to add to Hopwood' s method of merging software elements and 
auditing changes to child-parent comparison technique as taught by Leblang, in case Hopwood' s 
RMS comparing method does not already include one, because this would enable the 
synchronizing child version from its ancestor version with incremental difference extracting and 
identification of conflicts by means of tree-like branching, thus enabling better reconciliation of 
hierarchical versioned documents and possible removing of selective delta as taught by Leblang. 

Nor does Hopwood explicitly specify comparing versioned documents at a plurality of 
different subdivision levels. In view of the teachings by Hopwood's RMS file difference 
resolving and Leblang' s merge/unmerge at different levels of project/documents hierarchy, this 
limitation is implicitly disclosed in the combination of Hopwood/Leblang from above. 

Nor does Hopwood disclose preserving the further set of changes when unmerging from 
a later version. But in view of Leblang' s teachings (substractive merge - Note: substract Aa 
while maintaining Ab and Ac reads on preserving 2 nd level and unmerging the first set), it would 
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have been obvious for one of ordinary skill in the art at the time the invention was made to 
provide such delta recording and selective unmerging by Leblang because this would enable a bi- 
directional merging and generating on demand of more version combinations such to obviate the 
otherwise burden of systematically restarting the incorporation of deltas from a parent from the 
top ( see Leblang col. 25, lines 1-29). 

As per claim 2, this is a computer-readable medium version of claim 1. As for a medium 
to support the software product, Hopwood discloses use of workstations to develop the software 
building (e.g. Fig. 7) hence implicitly discloses the use of computer-readable medium. 
13. Claims 3, 7, and 39-42 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Skinner, USPN: 5,481,722 ( hereinafter Skinner) 

As per claim 3, Skinner discloses a method useful in developing software having 
multiple versioned documents, comprising: 

comparing a line of one documents to a current line of the another document (e.g. output 
table , branch deltas - Fig 7a-b; control line - col. 7, line 30 to col. 8, line 25; Fig. 6 - Note: the 
comparing of lines by lines text is implicitly disclosed because delta text lines 240 within each 
block delimited by control line reads on line division being compared to be part of a delta result); 
repeating second comparing step within this subdivision type (e.g. text lines - Fig. 6); 

But Skinner does not explicitly disclose determining whether there are more than a pre- 
determined number of differences between the lines; and indicate the differences. Skinner 
discloses tree-based comparing parent set of files against children set of files, each set having 
version levels associated with delta comparing (e.g. Fig. 8); hence has implicitly disclosed the 
paradigm in which one first version contains a certain number of resemblance, or predetermined 



Application/Control Number: 09/7 1 7,676 Page 1 3 

Art Unit: 2193 

number of resemblances - per version, and that another version contains some number of 
discrepancies on top of that first version (e.g. Fig. 8 - versions P: 7.7, 7.7.7, 7.7.2; CI: LI, L2, 
7.3); hence the concept of a number discrepancies being defined as a version and persisted, or 
accounted for during the tree-based comparing is disclosed. Based on such number of 
discrepancies or resemblances as recorded per versioned file as above, it would have been 
obvious for one skill in the art at the time the invention was made to provide Skinner' s tree 
version organization with a predetermined number of resemblance or discrepancies per version 
like that implied from Skinner's Fig, 8 so that while comparing a child at any level of the tree, as 
soon as such number surpasses a known number of a version for that same level, the version 
corresponding to that number is determined to no longer be the same and another version is to be 
generated; and this is implied from Skinner's intent as put forward in the text related to Fig. 8. 
As per claim 7, Skinner discloses computer medium ( col. 5, lines 52-67; Fig. 3-4) 
As per claim 39, Skinner discloses a method useful in developing software having 
multiple versioned documents, comprising: 

comparing subdivisions of one of the documents to a current subdivision of other 
document; and indicating differences therebetween ( e.g. start control line, end control line - 
Fig. 6; text line - Fig. 6; output table , branch deltas - Fig 7a-b; control line - col. 7, line 30 to 
col. 8, line 25). 

But Skinner does not explicitly disclose determining whether there are more than a pre- 
determined number of differences between the subdivisions. As from claim 3 above, Skinner 
discloses subdivision being a line; and based on the rationale using version creating from 
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Skinner's Fig. 8, the pre-determined number of differences would have been obvious for the 
same reasons as set forth in claim 3. 

As per claims 40 and 41, Skinner disclose multi-line sections and line differences 
{control line - col. 7, line 30 to col. 8, line 2; e.g. start control line, end control line - Fig. 6; text 
line - Fig. 6) 

As per claim 42, refer to claim 7. 
14. Claim 6 is rejected under 35 U.S.C. 103(a) as being unpatentable over Skinner, USPN: 
5,481,722; as applied to claim 3; in view of Panagiotis, DijfMm Page/Man-cgi 1.11, 1994 ( 
hereinafter Panagiotis) 

As per claim 6, Skinner does not explicitly disclose differences are characters. The 
comparing of line necessarily encompasses the going through of its elements; and based on the 
Skinner going through a text by iterating division type such as a line( start control line, end 
control line - Fig. 6; text line - Fig. 6) such line element checking is implicitly disclosed by 
Skinner. In case Skinner does not already provide subdividing a line into a character division to 
perform character comparison with a counterpart in the current line of the 2 documents, there is 
suggestion as to why Skinner should have done so. Skinner is using an Unix platform by Sun 
Microsystems, and suggests the use of command line utilities within such platform (see 
Background and col. 6, lines 10-32). In a man page for diff similar to Unix Man page, Panagiotis 
discloses line by line comparison with options -a or -c or -# and option i to ignore character and 
-b to address blanks; thus has strongly indicated partition a document into line and character 
subdivision while scanning a line. Thus , it would have been obvious for one skill in the art at 
the time the invention was made to provide the Unix utilities as taught by Panagiotis to Skinner 
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Sun Microsystems computer facilities to that the subdivision comparing as taught by Panagiotis 
is utilized because this would enable Skinner to make use of utilities already available in its 
platform and thereby be endowed with options as suggested above to selective address line-by- 
line pattern and its character subdivisions and make the document comparing process more time 
and cost efficient. 

15. Claims 13-14 are rejected under 35 USC 103(a) as being unpatentable over Leblang et 
al., USPN: 5,649,200, as applied to claim 11, in view of Howard, USPN: 5,600,834 ( hereinafter 
Howard). 

As per claims 13 and 14, Leblang discloses using delta recording as a result of 
comparing in the merge and indication conflicts due to alternative histories of child documents 
(Fig. 16) but fails to disclose marking of possible conflicts ( re claim 13) or actual conflicts ( re 
claim 14) in the merged document. Howard, in a method to reconcile versions of a file with 
generation of a merge document analogous to the combined merge by Leblang, discloses a 
document combining the results from reconciling documents with history of more than one 
versions (e.g. Fig. 4; col. 6, lines 35-48) and marking in this document of possible conflicts due to 
histories of child/parent documents (e.g. col. 12, lines 11-12). It would have been obvious for 
one of ordinary skill in the art at the time the invention was made to provide such information 
marking as suggested by Howard within the delta combination file as. taught by Leblang because 
it would provide additional information for the developer or version administrator to further 
effect verification or error-proofing on the combined merge output file prior to committing it to 
persistent storage or distribution to sites as suggested by Howard. 
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16. Claim 30 is rejected under 35 U.S.C. 103(a) as being unpatentable over Carrier III et al., 
USPN: 5,903,897. 

As per claim 30, Carrier does not disclose including screen shots in the non-versioned 
documents although Carrier discloses problem reports to associate with a release (re claim 29). 
Official notice is taken that the use of screen/snap shot to take instant capture of a malfunction 
messages or error display/pop-ups during a debug for reporting on a software execution or 
product assessment such as suggested by Carrier was a well-known practice at the time of the 
invention. Hence, it would have been obvious for one of ordinary skill in the art at the time the 
invention was made to include in the association file as taught by Carrier any debug information, 
e.g. including screen shots as taught by known practices because this would provide graphical 
evidence for the developer to better address conflicts or bugs thereby ensure quality in delivering 
versioned elements for the build. The arguments therefore are not persuasive. 

Response to Arguments 

17. Applicant's arguments filed 2/22/2005 have been fully considered. Some arguments are 
becoming moot in view of the new grounds of rejection; and some are not persuasive. 
Concerning the above arguments, following are the Examiner's observation and response 
thereto. 

Rejections under 35 USC §102: 
(A) Applicants have submitted that no where in Leblang's Fig. 13 and 16 is described or 
mentioned about 'indicating possible conflicts' ( Appl. Rmrks, pg. 10, bottom, pg. 1 1, top). The 
rejection is now pointing to where the possible delta found can be resolved to yield the actual 
conflicts. The claim is not specific as to what exactly 'indicating actual or possible conflicts' 
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amount to; hence a broad and reasonable interpretation has been used, i.e. possible meaning not 
entirely resolved, and actual meaning finally resolved. 

(B) Applicants have submitted that no where in Carrier's release form is described or 
mentioned about 'listing non-versioned documents 5 ( Appl. Rmrks, pg. 11, middle, re claim 22) 
and that there is no teaching of 'entry . . . designate . . . non-versioned . . and that Carrier's 
release form only list source modules (Appl. Rmrks, pg. 11, middle, re claim 27). The rejection 
has pointed out a Carrier's teaching such as incorporating within a load data and per check- in file 
a problem report with label and name/version associated with each check-in source document 
name; and that reads on what Applicants refer to as non-versioned document being listed as 
useful information and being entered in the association file. 

(C ) Applicants have submitted that no where in Hopwood's master copy is not suggesting or 
teaching removal of build-specific changes ( Appl. Rmrks, pg. 12, middle, re claim 3 1). The 
rejection now has redirected the archiving, the master copy and its use in the RMS change 
tracking in conjunction with team member and files being checked in/out for modification in 
view of the REVERT teaching. The combination of all such teachings leads to the fact that a file 
can be reverted and based on the history of changes information, such REVERTmg reads on 
removal of build-specific. 

Rejections under 35 USC §103(a): 
(D) Applicants have submitted that no where is Leblang teaching 'indicating possible 
conflicts' and that Hopwood's master copy is not suggesting or teaching removal of build- 
specific changes ( Appl. Rmrks, pg. 13, middle, re claim 1). The 2 limitations have been 
addressed in sections A and C above respectively. 
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(E) Applicants have submitted that Skinner or Panagiotis does not have 'determining whether 
... pre-determined number ... indicating the differences' ( Appl. Rmrks, pg. 13, bottom, re 
claims 3, 39). The arguments are moot in view of the new grounds of rejection. 

Conclusion 

18. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Tuan A Vu whose telephone number is (272) 272-3735. The 
examiner can normally be reached on 8AM-4:30PM/Mon-Fri. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Kakali Chaki can be reached on (571)272-3719. 

The fax phone number for the organization where this application or proceeding is 
assigned is (571) 273-3735 ( for non-official correspondence - please consult Examiner before 
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using) or 703-872-9306 ( for official correspondence) or redirected to customer service at 571- 
272-3609. 

Any inquiry of a general nature or relating to the status of this application should be 
directed to the TC 2100 Group receptionist: 571-272-2100. 

Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 

VAT 

May 9, 2005 




